InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/sip/93mar.min

Text File | 1993-05-13 | 13KB | 347 lines

CURRENT_MEETING_REPORT_


Reported by Christian Huitema/INRIA

Minutes of the Simple Internet Protocol Working Group (SIP)

The SIP Working Group met Tuesday morning and Wednesday afternoon.  The
Tuesday session was devoted to the finalization of the SIP
specification, specially in light of the first interoperability
experiences.  The Wednesday session was devoted to the analysis of
routing protocols.

SIP Specification

The first speaker in the session was Steve Deering, who reviewed the
recent ``precisions'' to the SIP specification:


   o The first 32 flow-ids values have been ``reserved'' for IP ``TOS''
     compatibility.

   o The formats for the LSR and reassembly payloads has been slightly
     modified, so that the ``payload type'' arrives first.

   o The payload type 0 has been reserved for hop by hop options.
     Routers are supposed to inspect the payload type of every packets.
     If this type is set to zero, then ``hop by hop'' options should be
     examined.


A generic format for hop by hop has been defined:  after a generic
``option header'' expressing the embedded payload type and the number of
64 bit words used to carry the option, each hop by hop option is
represented by a set of 32 bit words; the first octets include the
option type and the option length, expressed as a number of 32 bit
words.  There was a discussion on the adequacy of using the 32 bit words
units, and a proposal to use a byte count instead; the Working Group
turned this down, and reached consensus on 32 bit word count.  Steve
then presented the requirements for ``option ordering''.  To sum up, it
is required to have the following order in the packets:


   o Sip header
   o Hop by hop option, if present
   o Source route option, if present
   o Fragmentation header, if present
   o Data


Then, Steve presented a change in terminology:  ``Cluster address''
instead of ``anyone'' address.  The Working Group noted the requirement
for two precisions in the specifications:

                                   1





  1. Multicast addresses cannot be used in source routes.
  2. Cluster addresses should never be used as source addresses.  This
     implies that cluster addresses should not be used for TCP
     connections, as they cannot be used as ``reply'' addresses.


Steve also mentioned that the new specification will include precisions
on the ``pseudo checksum computation'' (e.g., for ICMP and IGMP), in
particular when the ``C'' bit is set.

IEEE-802 Address Format

The discussion switched then to the definition of an IEEE-802 address
format.  Steve Deering and Bob Hinden presented a format where a SIP
address can be build by prepending a 16 bit header to an IEEE-802 48 bit
address.


   ------------------------------------
   | prfx | Subnet | IEEE-802 address |
   ------------------------------------


The 16 bit prefix, in this proposition, is divided in two fields, a 6
bit prefix for recognizing this address as an IEEE-802 address, and a 10
bit ``subnet identifier'' to identify the ``local network'' to which the
station is connected.  This triggered a discussion on the usage of this
addresses and the proper length for the prefix and subnet field, with
the following conclusions:


   o These addresses should only be used as long as no ``real SIP''
     address has been assigned to the station.
   o They should never be advertized outside of the ``autonomous
     system'', i.e.  through IDRP.
   o The prefix should be 8 bit long, and the subnet also 8 bit.  The
     need to study the interaction with the DNS was also mentioned.


Security Labelling

The last speaker in Tuesday's session was Randy Atkinson, who had
submitted a ``SIPSO'' draft, describing a ``security labeling'' option,
and also presented the various possibilities for designing an end-to-end
security option based on SP-3 and NLSP. The discussion of the labeling
option was marked by the following comments:


   o The main rationale for the labeling proposal was ``compatibility
     with IPv4''.  Some IPv4 routers used in ``secure environment'' use


                                   2





     the labeling service, and would suffer from ``reduced
     capabilities'' if the function was not available.

   o It was pointed out that security label alone were not very useful
     and that security should be addressed ``globally'', e.g.  also in
     the routing architecture.

   o Randy Atkinson mentioned that one rationale for the labeling option
     was also to prevent negative feelings, e.g.  propagation of the
     false impression that SIP would be more ``insecure'' than IPv4
     because it would be missing the option.


In fact, all members agreed that end-to-end security was much more
important.  Randy continued his presentation by explaining how SP-3 is
used to encapsulate and protect IP packets.  It was decided to track the
IPv4 efforts on the subject, and to come out with a SIP version of their
proposal as soon as the IPv4 drafts stabilize.

Session 2

The first point on the Agenda of the Wednesday session was the review of
the ``DNS for SIP'' draft.  The draft defines an ``AA'' type record for
storing the 64 bit SIP addresses, and a reverse tree under
``sip-addr.arpa''.  It was decided after discussions to align the format
of the reverse addresses with the ``standard'' external format of SIP
addresses.  The name corresponding to the SIP address:


     0abc:f120:138.96.24.84


will be obtained through the inverse domain name:


     84.24.96.138.f120.abc.sip-addr.arpa


The SIP-DNS Draft will be updated accordingly.

SIP Version of Three Routing Protocols

The next part of the session was devoted to the study of the ``SIP''
version of three routing protocols, RIP, OSPF and IDRP.


   o The SIP-RIP draft was presented by Gary Malkin.  The draft is
     derived from RIP-2, with the following modifications:

      -  Addresses are 64 bit,

                                   3





   -  Bit masks are contiguous,
   -  The metric is designed to converge on the best throughput,
      instead of the lesser number of hops.

  Gary presented then three possible amendments to SIP-RIP, proposed
  by himself and Yakov Rekhter:

   1. As the SIP routers can easily now the MTU ofterface on which a
      RIP packet is transmitted, there is no need for a standard 576
      length limit -- they can as well make packets as big as the MTU
      allows.
   2. By using an algorithm suggested by () and by () in the 1989
      SIGCOM conference, it is possible to remove the ``bouncing
      effect'' and to compute loop free routes.  The cost is to add
      one extra address information per routing entry, and one
      computation step before propagating routes.
   3. By using the ``route on demand'' improvement suggested in a
      draft by ??

  After discussion, it was decided that modification (1) and (2)
  should be incorporated in the current draft, and that (3), which
  represent a substantial although compatible improvement, should be
  specified in a separate document.

o The SIP-OSPF Draft was presented by Christian Huitema.  The main
  features of the Draft are:

   -  Regular OSPF, running over IPv4
   -  Two additional LSAs to import SIP information and an additional
      bit in the router-LSA to indicate SIP capability.
   -  ``Integrated routing'' in order to ease the migration from IPv4
      to SIP, after which a native OSPF for SIP would be defined.

  A number of points were raised:

   -  The IPv4 address to use when tunneling should be that of the
      selected interface to the dual SIP/IPv4 host.  There should be
      a way to identify this interface address.
   -  The translation between SIP and IPv4 formats should only take
      place in border routers.
   -  We should avoid doing ``double transition''.  The specification
      should be definitive.
   -  We should specify clearly whether ``SIP'' areas are requested
      to have the same boundaries as ``IPv4'' areas.
   -  When defining new LSAs, we should perhaps be able to specify a
      ``multiprotocol'' format.



                                4





     It was decided that all detailed discussions of OSPF in SIP would
     be carried on in the SIP Working Group.

   o The IDRP for SIP draft written by Sue Hares was presented by Yakov
     Rekhter.  Options for representing SIP addresses and for
     identifying SIP ``autonomous systems'' were discussed, as well as
     the need to define a document for multicast routing.


Bill Simpson presented the provisional results of the working party on
ES/IS, ARP and autoconfiguration.

Attendees

Kannan Alagappan         [e-mail]
Guy Almes                [e-mail]
Michael Anello           [e-mail]
Randall Atkinson         [e-mail]
David Battle             [e-mail]
Tom Benkart              [e-mail]
Fred Bohle               [e-mail]
David Bolen              [e-mail]
Erik-Jan Bos             [e-mail]
Robert Braden            [e-mail]
Monroe Bridges           [e-mail]
David Bridgham           [e-mail]
Al Broscius              [e-mail]
Jeff Carman              [e-mail]
Kevin Carosso            [e-mail]
David Carr               [e-mail]
John Chang               [e-mail]
Rob Coltun               [e-mail]
Steve Deering            [e-mail]
Osmund DeSouza           [e-mail]
Chas DiFatta             [e-mail]
Ralph Droms              [e-mail]
David Dubois             [e-mail]
Pierre Dupont            [e-mail]
Tom Easterday            [e-mail]
Dino Farinacci           [e-mail]
Dennis Ferguson          [e-mail]
Eric Fleischman          [e-mail]
Paul Francis             [e-mail]
Peter Furniss            [e-mail]
John Gawf                [e-mail]
Joseph Godsil            [e-mail]
Ramesh Govindan          [e-mail]
Danny Hanson             [e-mail]
John Hascall             [e-mail]
Robert Hinden            [e-mail]
Jeffrey Honig            [e-mail]
Steven Hubert            [e-mail]
Christian Huitema        [e-mail]

                                   5





John Ioannidis           [e-mail]
Phil Irey                [e-mail]
Ronald Jacoby            [e-mail]
David Johnson            [e-mail]
Laurent Joncheray        [e-mail]
Dan Jordt                [e-mail]
Doug Karl                [e-mail]
Kenneth Key              [e-mail]
Charley Kline            [e-mail]
Moshe Kochinski          [e-mail]
Mark Laubach             [e-mail]
Mark Lewis               [e-mail]
Yu-Lin Lu                [e-mail]
Paul Lustgraaf           [e-mail]
Charles Lynn             [e-mail]
Bruce Mackey             [e-mail]
Carl Madison             [e-mail]
Gary Malkin              [e-mail]
David Meyer              [e-mail]
Greg Minshall            [e-mail]
Matthew Morrisey         [e-mail]
John Moy                 [e-mail]
Erik Nordmark            [e-mail]
William Owens            [e-mail]
Michael Patton           [e-mail]
Gaige Paulsen            [e-mail]
John Penners             [e-mail]
Willi Porten             [e-mail]
David Reese              [e-mail]
Yakov Rekhter            [e-mail]
Manoel Rodrigues         [e-mail]
Yzhak Ronen              [e-mail]
William Simpson          [e-mail]
Subbu Subramaniam        [e-mail]
Terry Sullivan           [e-mail]
Fumio Teraoka            [e-mail]
Kamlesh Tewani           [e-mail]
Richard Thomas           [e-mail]
Susan Thomson            [e-mail]
L. Stuart Vance          [e-mail]
John Veizades            [e-mail]
Dinesh Verma             [e-mail]
Warren Vik               [e-mail]
Ruediger Volk            [e-mail]
Chuck Warlick            [e-mail]
Scott Wasson             [e-mail]
Von Welch                [e-mail]
Fred Whiteside           [e-mail]
Steven Willis            [e-mail]
Richard Woundy           [e-mail]
Charles Young            [e-mail]



                                   6